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APPLICATION PROGRAM INTERFACE FOR 
TRANSFORMING HETEROGENEOUS 
PROGRAMS 

RELATED APPLICATIONS 

The present application is related to U.S. patent applica- 
tion Sen No. 09/343,805 entitled "Translation and Transfor- 
mation of Heterogeneous Programs", U.S. patent application 
Ser. No. 09/343,248 entitled "Instrumentation and Optimi- 
zation Tools for Heterogeneous Programs", U.S. patent 
application Ser. No. 09/343,287 entitled "Cross Module 
Representation in Heterogeneous Programs", and U.S. 
patent application Ser. No. 09/343,279 entitled "Shared 
Library Optimization for Heterogeneous Programs", all of 
which being filed on the same day as the present application 
and assigned to the same assignee as the present application. 

FIELD OF THE INVENTION 

This invention relates generally to programming tools, 
and more particularly to translating code between computer 
architectures. 

COPYRIGHT NOTICE/PERMISSION 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright 
rights whatsoever. The following notice applies to the soft- 
ware and data as described below and in the drawings 
hereto: Copyright© 1998, Microsoft Corporation, All Rights 
Reserved. 

BACKGROUND OF THE INVENTION 

In a new programming paradigm, a program is now a 
collection of components. Each component publishes an 
interface without exposing its inner details. T3}usra"conu?o- 
nent-can-intemally -existnr any form:rIntel-x86 : binar^^itel 
I'A-64-binary,-Visual"Basic(VB) byte-codesrJava~crass files, , 
or any Virtual Machine (VM) binary. A^helerogeneousrt, 
prog ram-consists -of-components m dif ferenlfonm Hetero- 
geneous programs already exist in some environments: in 
the Microsoft Windows 32-bit environment, a Visual Basic 
program is compiled into VB byte codes that can call 
native -compiled functions in a separate dynamic linked 
library. Similarly Java class files can call native functions. 
IntePs IA-64 architecture allows IA-64 code to co-exist with 
x86 code. 

To understand the behavior of a heterogeneous program, 
all of its components, regardless of their form, have to be 
instrumented and analyzed in the same framework, 
otherwise, only partial information will be collected. It is 
important to note that systems that have been ported to 
several architectures are not sufficient to handle heteroge- 
neous programs. For example, a system for VB byte codes 
that has been ported to x86 cannot provide a complete 
execution time analysis of a heterogeneous program con- 
sisting of VB byte codes and native x86 because each system 
operates in isolation on its own input. 

Further, a heterogeneous program may consist of hetero- 
geneous components. A heterogeneous component is a 
single component consisting of routines in different instruc- 
tion sets. As the interface is well defined, components 
internally can use any instruction set. Each instruction set 
has its own advantages such as execution time, portability, 
and size. 
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All previous systems have been designed for homoge- 
neous programs: conventional programs consisting of com- 
ponents in the same form. Some systems have been targeted 
to different architectures, but cannot work with heteroge- 
neous programs. None of these systems can generate a 
heterogeneous component. 

A large number of systems have been developed to help 
analyze and optimize homogeneous programs. The creation 
of "Pixie" by MIPS Computers Systems, Inc. in 1986 started 
a class of basic block counting tools by inserting predeter- 
mined sequence of instructions to record execution frequen- 
cies of basic blocks. "Epoxie" extended the technique by 
using relocations to eliminate dynamic translation over- 
heads. David W. Wall. Systems for late code modification, in 
Code Generation — Concept, Tools Techniques, pp. 
275-293, (Robert Giegrich and Susan L. Graham, eds, 
1992). "QPT" further extended the technique by construct- 
ing spanning trees to reduce the number of basic blocks that 
are instrumented. James Larus and Thomas Ball, Rewriting 
executable files to measure program behavior, Software, 
Practice and Experience, vol. 24, no. 2, pp 197-218 (1994). 
"Purify" instruments memory references to detect out-of- 
bounds memory accesses and memory leaks. Reed Hastings 
and Bob Joyce, Purify: Fast Detection of Memory Leaks and 
25 Access Errors, Proceedings of Winter Usenix Conference, 
January 1992. 

"OM" allowed general transformations to be applied to a 
binary by converting the binary to an intermediate repre- 
sentation that can be easily manipulated. Amitabh Srivastava 
and David Wall, A Practical System for Intermodule Code 
Optimization at Link Time, Journal of Programming 
Language, 1(1): 1-18 (1993). OM has been implemented on 
MIPS, DEC Alpha and Intel x86 architectures. "EEL" uses 
a similar technique and provides an editing library for Sun 
SPARC architectures. James R. Larus and Eric Schnarr, 
EEL: Machine -Independent Executable Editing, Proceed- 
ings of SIGPLAN' 95 Conference on Programming Lan- 
guage Design and Implementation (1995). "Alto" and 
"Spike" are optimizers for the DEC Alpha architectures. K. 
De Bosschere and S. Debray, Alto: a Link-Time Optimizer 
for the DEC Alpha. Technical Report TR-96-16, Computer 
Science Department, University of Arizona (1996). David 
W. Goodwin, Interprocedural Dataflow Analysis in an 
Executable Optimizer, Proceedings of SIGPLAN* 97 Con- 
ference on Programming Language Design and Implemen- 
tation (1997). 

"ATOM" extended OM by providing a flexible instru- 
mentation interface for the DEC Alpha and Intel x86 sys- 
tems. Amitabh Srivastava and Alan Eustace, ATOM: A 
System for Building Customized Program Analysis Tools, 
Proceedings of SIGPLAN' 94 Conference on Programming 
Language Design and Implementation (1994). However, 
ATOM does not allow modifications to a binary. "Etch" 
provided a similar system for x86 and "BIT' for Java byte 
codes. T. Romer, G. Voelker, D. Lee, A. Wolman, W. Wong, 
H. Levy, B. Chen, and B. Bershad, Instrumentation and 
Optimization of Win32flntel Executables Using Etch, Pro- 
ceedings of the USENIX Windows NT Workshop (1997). 
Han Lee and Benjamin Zorn, BIT: A Tool for instrumenting 
60 Java bytecodes. Proceedings of the 1997 USENIX Sympo- 
sium on Internet Technologies and Systems (1997). 

None of these systems work on heterogeneous programs. 
Some of them have been ported to multiple architectures but 
they provide only a partial view when applied to heteroge- 
neous programs as each implementation operates on its input 
in isolation. AltK6ug£IINO^ 
the re^resentation^osjsrj^^ 
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trary transformations and is not sufficient to handle hetero- the present invention. The following detailed description is, 

geneous programs. None of these systems can generate therefore, not to be taken in a limiting sense, and the scope 

heterogeneous components. ATOM provides a flexible inter- of the present invention is defined only by the appended 

face for instrumentation only. claims. 

zj Therefore, there is a need to represent a heterogeneous A. The detailed description is divided into four sections. In 

// program and its heterogeneous components in a fashion that \ * the first section, the hardware and the operating environment 

f I permits a user to evaluate the behavior of the program to be ] in conjunction with which embodiments of the invention 

\A evaluated across architectural boundaries and to optimize Lmay be practiced are described. In the second section, a 

\lbe entire program. v system level overview of the invention is presented. In the 

^ 10 third section, functions of an exemplary embodiment of the 

SUMMARY OF THE INVENTION invention are described. Finally, in the fourth section, a 

The above-mentioned shortcomings, disadvantages and conclusion of the detailed description is provided. 

problems are addressed by the present invention, which will TT A , ^ n • „ * 

f . , ^ . J , * , . - „ . . Hardware and Operating Environment 

be understood by reading and studying the following speci- r 

fication. FIG. 1 is a diagram of the hardware and operating 

An application program interface (API) provides environment in conjunction with which embodiments of the 

navigation, query, and modification functions to be per- invention may be practiced. The description of FIG. 1 is 

foimeiitoii^ui±iterm^ intended to provide a brief, general description of suitable 
g-enib^jg^ TOelJE3»nsks-of^ 20 computer hardware and a suitable computing environment in 

platform^eutralnnsTr^ conjunction with which the invention may be implemented, 

elerflpts conuuorfSkp^ Although not required, the invention is described in the 

data" '^SS^M^pmo^miT and 'components. The API is general context of computer-executable instructions, such as 

c^h^dby an end user, pre-defined tools, and an output program modules, being executed by a computer, such as a 

translator to add, delete, or modify the IR elements, to 25 personal computer. Generally, program modules include 

instrument the IR to gather statistics on its operation, to routines, programs, objects, components, data structures, 

optimize the IR, and to output the IR into code for a specific etc., that perform particular tasks or implement particular 

architecture or architectures for execution. The basic abstract data types. 

navigation, query, and modification functions of the API are Moreover, those skilled in the art will appreciate that the 

supplemented by specialized functions. 30 invention may be practiced with other computer system 

/because the API operates on the intermediate represen- configurations, including hand-held devices, multiprocessor 

tation of the heterogeneous program or component, the systems, microprocessor-based or programmable consumer 

'caller of the API can examine and transform the code as a electronics, network PCs, minicomputers, mainframe 

whole, crossing platfona^specific:boundaries;:4o achieve a computers, and the like. The invention may also be practiced 

more^ffiaentij^ 35 m distributed computing environments where tasks are 

vX- . • a.' j -i_ « _ *u a a performed by remote processing devices that are linked 

The present invention describes systems, methods, and £ , 3 . * * _ ,. 4 A , 

f j * i ,. c . T , 4V , through a communications network. In a distributed com- 

computer-readable media of varying scope. In addition to .. . . A i u 1 * a ■ 

the aspects and advantages of the present invention j« environment, program modules may be located in 

describedin this summary, former aspects and advantagesof bo * local remote memory storage devices, 

the invention will become apparent by referencing the 40 The exemplary hardware and operating environment of 

drawings and by reading the detailed description that fol- FIG. 1 for implementing the invention includes a general 

lows purpose computing device in the form of a computer 20, 

including a processing unit 21, a system memory 22, and a 

BRIEF DESCRIPTION OF THE DRAWINGS system bus 23 that operatively couples various system 

m _ ^ . . . , .-45 components, including the system memory 22, to the pro- 

FIG. 1 is a diagram of the hardware and operating cc J ngunit2 l.There maybe only one or there may be more 

environment in conjunction with wfnch embodiments of the ^ ^ processing ^ 21> such that the proce ssor of 

mvention may be practiced; computer 20 comprises a single central-processing unit 

FIG. 2A is a diagram illustrating a system-level overview (CPU), or a plurality of processing units, commonly referred 

of an exemplary embodiment of the invention; 5Q t0 as a parallel processing environment. The computer 20 

FIGS. 2B, 2C and 2D are diagrams illustrating additional may be a conventional computer, a distributed computer, or 

details of the processes shown in FIG. 2A; and any other type of computer; the invention is not so limited. 

FIG. 3 is a diagram of an intermediate representation The system bus 23 may be any of several types of bus 

hierarchy used by the exemplary embodiment of FIG. 2A. structures including a memory bus or memory controller, a 

55 peripheral bus, and a local bus using any of a variety of bus 

DETAILED DESCRIPTION OF THE architectures. The system memory may also be referred to as 

INVENTION simply the memory, and includes read only memory (ROM) 

In the following detailed description of exemplary 24 and random access memory (RAM) 25. A basic input/ 

embodiments of the invention, reference is made to the output system (BIOS) 26, containing the basic routines that 

accompanying drawings which form a part hereof, and in 60 help to transfer information between elements within the 

which is shown by way of illustration specific exemplary computer 20, such as during start-up, is stored in ROM 24. 

embodiments in which the invention may be practiced. The computer 20 further includes a hard disk drive 27 for 

These embodiments are described in sufficient detail to reading from and writing to a hard disk, not shown, a 

enable those skilled in the art to practice the invention, and magnetic disk drive 28 for reading from or writing to a 

it is to be understood that other embodiments may be utilized 65 removable magnetic disk 29, and an optical disk drive 30 for 

and that logical, mechanical, electrical and other changes reading from or writing to a removable optical disk 31 such 
may be made without departing from the spirit or scope of as a CD ROM or other optical media. 
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The hard disk drive 27, magnetic disk drive 28, and embodiments of the invention may be practiced may be a 

optical disk drive 30 are connected to the system bus 23 by conventional computer, a distributed computer, or any other 

a hard disk drive interface 32, a magnetic disk drive inter- type of computer; the invention is not so limited. Such a 

face 33, and an optical disk drive interface 34, respectively. computer typically includes one or more processing units as 

The drives and their associated computer-readable media 5 its processor, and a computer-readable medium such as a 

provide nonvolatile storage of computer-readable memory. The computer may also include a communications 

instructions, data structures, program modules and other device such as a network adapter or a modem, so that it is 

data for the computer 20. It should be appreciated by those ablc to commumcat ivcly couple to other computers, 
skilled in the art that any type of computer-readable media 

which can store data that is accessible by a computer, such 1Q System Level Overview 

as magnetic cassettes, flash memory cards, digital video 

disks, Bernoulli cartridges, random access memories Asystem level overview of the operation of an exemplary 

(RAMs), read only memories (ROMs), and the like, may be embodiment of the mwmlonjs^scribed Jby reference to 

used in the exemplary operating environment. FIGS. 2 A-D • Achej^rpge¥c,6^ 

Anumber of program modules may be stored on the hard 15 executable, components, T such~^as^rCprogr^^ 

disk, magnetic disk 29, optical disk 31, ROM 24, or RAM shMc'drlibrSri^ 

25, including an operating system 35, one or more applica- (platforms)^ FIG. 2A shows a 

tion programs 36, other program modules 37, and program system 200 that translates and transforms components in a 

data 38. A user may enter commands and information into heterogeneous program. The system 200 comprises an input 

the personal computer 20 through input devices such as a 20 translator (reader) 210, a transformation module 230, and an 

keyboard 40 and pointing device 42. Other input devices out P ut translatorjwriter) 240. AlDhree^mpdules ^or^with 

(not shown) may include a microphone, joystick, game pad, a^jgfcle^ 

satellite dish, scanner, or the like. These and other input referred as an "intermediate repr^^apVL(IR)>20. The 
devices are often connected to the processing unit 21 / IR is a of pseudo-instnictions for a stack-based logical^ 

through a serial port interface 46 that is coupled to the ^ machine with an unlimited number of registers that represent / 
system bus, but may be connected by other interfaces, such \) ht functionality of the heterogeneous program. /J 
as a parallel port, game port, or a universal serial bus (USB). The reader 210 creates an IR 220 from an executable 

A monitor 47 or other type of display device is also component (EXE) 201. The reader 210 is a two-stage 

connected to the system bus 23 via an interface, such as a process as shown in FIG. 2B. First, the executable 201 is 

video adapter 48. In addition to the monitor, computers 30 parsed 211 into its basic blocks of code and data using 

typically include other peripheral output devices (not information provided in a program database file (PDB) 202. 

shown), such as speakers and printers. As well-known in the art, a basic code block is defined as a 

The computer 20 may operate in a networked environ- code block having a single entry point and a single exit 

ment using logical connections to one or more remote point. In an alternate embodiment, all the work performed 

computers, such as remote computer 49. These logical 35 by me parser 211 is input directly into the second stage of the 

connections are achieved by a communication device reader 210, thus skipping the parsing process, 
coupled to or a part of the computer 20; the invention is not Once the code and data blocks are identified, an IR 

limited to a particular type of communications device. The creation process 212 evaluates each platform-dependent 

remote computer 49 may be another computer, a server, a instruction on a block-by-block basis. There are very large 

router, a network PC, a client, a peer device or other 40 set of~commqn~instractionsregardless-of ^architecture, i.e., 

common network node, and typically includes many or all of moveTlitoTeT^dr^^^ 

the elements described above relative to the computer 20, plajform-neutral IR instiuctioa^ForRISC (reduced instruc- 

although only a memory storage device 50 has been illus- tion set computer) lircmtectures, most, if not all, instructions 

trated in FIG. 1. The logical connections depicted in FIG. 1 can be easily translated into a single platform-neutral IR 

include a local-area network (LAN) 51 and a wide-area 45 instruction. On the other hand, CISC (complex instruction 

network (WAN) 52. Such networking environments are set computer) architectures, such as the Intel x86 family, 

commonplace in offices, enterprise-wide computer contain complex instructions that provide the function of 

networks, intranets and the Internet. multiple instructions. In one exemplary embodiment, the 

When used in a LAN-networking environment, the com- platform-dependent instructions that have a single platform- 

puter 20 is connected to the local network 51 through a 50 neutral IR instruction counterpart are translated into that 

network interface or adapter 53, which is one type of platform-neutral instruction, while complex instructions are 

communications device. When used in a WAN-networking replicated as-is within the IR through an extended version of 

environment, the computer 20 typically includes a modem the basic IR instruction. A replicated complex instruction is 

54, a type of communications device, or any other type of marked with a signature that denotes its architecture. The 

communications device for establishing communications 55 output translator 240 recognizes a signed complex instruc- 

over the wide area network 52, such as the Internet. The tion and processes it as described further below. In an 

modem 54, which may be internal or external, is connected alternate embodiment, a complex instruction is represented 

to the system bus 23 via the serial port interface 46. In a by a set of platform-neutral IR instructions that perform the 

networked environment, program modules depicted relative equivalent function. 

to the personal computer 20, or portions thereof, may be eo After the instructions in the code blocks have been 

stored in the remote memory storage device. It is appreciated translated, the IR creation process 212 creates a logical 

that the network connections shown are exemplary and other hierarchical view of the executable 201 as illustrated in FIG. 

means of and communications devices for establishing a 3. All architectures share the basic concepts of instructions 

communications link between the computers may be used. 305, code blocks 304, data blocks 306, components 302, and 

The hardware and operating environment in conjunction 65 procedures 303, so the IR hierarchy 300 enables the user to 

with which embodiments of the invention may be practiced understand the structure of the intermediate representation 

has been described. The computer in conjunction with which of a heterogeneous program 301. The code blocks are 
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logically connected as specified in the EXE file 201 so that 
the blocks can be more easily manipulated during the 
transformation process 230. Procedures are determined by 
following the logical connections using information pro- 
vided in the PDB file 202. Procedures are collected together 
to create the program components. Little or no optimization 
of the program is performed by the creation process 212 
since it is desirable that the intermediate representation be as 
close to what the programmer originally wrote as possible. 

However, tracing the logical connections to determine the 
procedures can result in more procedures being created than 
originally coded by the programmer. Therefore, the creation 
process 212 annotates, or "decorates," the hierarchy 300 
with the user names supplied in the symbol table for the 
EXE 201. The annotations enable the user to understand 
how the IR control flows and how the elements of the IR 
hierarchy correspond to the procedures and the components 
in the original code so the appropriate transformations can 
be applied to the IR. The annotations are maintained in data 
structures for the procedures during the transformation pro- 
cess and output by the output translator 240. 

At the end of the creation of the IR hierarchy, all instruc- 
tions are represented in the hierarchy as IR instructions 
within code blocks so that there is no differentiation between 
code written for one platform and code written for a second 
platform. The creation of the IR and an exemplary embodi- 
ment of the IR hierarchy are described in detail in the related 
"Translation and Transformation" patent application. 

Once the intermediate representation is complete, the user 
is allowed to manipulate the code and data (illustrated by the 
IR transformation module 230) through an application pro- 
gram interface (API) 250. The exemplary embodiment of the 
system 200 provides some pre-defined tools 231 (FIG. 2C) 
used to instrument and optimize the IR that are guaranteed 
to be safe in that the tools will evaluate a change requested 
by the user and only manipulate the code in an appropriate 
manner. The API 250 also permits the user direct access 232 
to the IR to navigate through the IR and to make changes, 
such as moving blocks between procedures, modifying 
blocks, rearranging the logical connections between blocks, 
and changing the platform -specific instruction set for a code 
block. The tools 231 are described in detail in the related 
"Instrumentation and Optimization Tool" patent application. 
The API 250 is described in the next section. 

By instrumenting the IR using the tools 231, the user can 
now watch the interrelationship between the various com- 
ponents of a heterogeneous program and determine if a 
block of code contained in one component is heavily used by 
another component, and therefore that block of code should 
be moved out of the first component and placed into the 
second component to speed up execution. This process is 
described in detail in the related "Shared Library Optimi- 
zation" patent application. Alternately, the user may decide 
to copy, instead of move, the code into the second 
component, a process referred to in the art as "code repli- 
cation." A common optimization technique called "inlining" 
utilizes code replication. 

The transformed IR is now input into the output translator 
240. The output translator 240 operates on the IR in two 
phases as shown in FIG. 2D: a linker phase 241 that resolves 
the logical connections into absolute addresses in an address 
space for a modified version of the executable, and a writer 
phase 242 that assembles the IR into the modified version of 
the executable (EXE 1 ) 203. The blocks in the executable 203 
can be emitted by the writer 242 for their original platform, 
or can be emitted for a different platform. 
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The linker 241 must maintain the semantics of the code of 
the hierarchy when resolving the addresses, i.e., preserve the 
logical connections between blocks and the location of 
referenced data. The linker 241 determines the size of each 
code block based on the length of each instruction in the 
block. The linker 241 is also responsible for adding when- 
ever prologue and epilogue code necessary to "glue" 
together contiguous blocks that will be assembled into 
different platform-dependent instructions. As part of the 
address resolution, the linker 241 also can perform limited 
code modification or optimization. For example, assume that 
prior to the transformation process 230, there was a jump 
between two code blocks, but those blocks are now con- 
tiguous. In this case, the linker 241 removes the now- 
unnecessary jump and lets the logic flow fall through to the 
second block. Because the hierarchy extends down to the 
instruction level and is consistent regardless of the manipu- 
lation performed by the user, the linker 241 has more 
knowledge of the placement of instructions than did the 
programmer. Thus, in architectures in which instructions 
have both a long and short form depending on the location 
they are addressing, the linker 241 chooses the appropriate 
instruction size, which can be a better choice than that 
originally made by the programmer. 

The writer 242 assembles each IR instruction into its 
platform-dependent counterpart based on the architecture 
specified in the code block. In an exemplary embodiment in 
which complex instructions are replaced in the IR, if the 
complex instruction is being written to the same platform, 
the writer 242 merely emits the instruction. If the complex 
instruction is designated to be translated into a different 
architecture, the writer 242 creates the appropriate set of 
platform-specific instructions to perform the same function 
as the original, complex instruction. 

As part of the EXE' 203, the writer 242 creates an emitted 
block information data structure containing the annotations 
created by the reader process 210 for each block in the 
executable. This allows the EXE' 203 to be iterated through 
the entire process 200 as many times as desired (represented 
by phantom arrow 260 and described in the related "Trans- 
lation and Transformation" patent application), while 
enabling the user to distinguish the original procedures from 
those added in a previous iteration. In an alternate 
embodiment, the emitted block information is combined 
with the PDB file 202 to create a new version of the program 
database file (PDB 1 ) 205 (shown in phantom). The output 
translation process 240 is described in detail in the related 
"Cross Module Representation" patent application. 

In an alternate exemplary embodiment of the translation 
and transformation system 200 not illustrated, the IR con- 
taining the absolute addresses assigned by the linker 241 is 
used as input into the IR creation process 212 for further 
iteration through the system 200. One of skill in the art will 
immediately appreciate that much of the work performed by 
the creation process 212 as described above can be skipped 
when iterating the modified IR through the system 200. This 
embodiment allows the user to transform a heterogeneous 
program in stages rather than having to make all the changes 
in a single pass through the system 200. The system level 
overview of the operation of an exemplary embodiment of 
the invention has been described in this section of the 
detailed description. A translation and transformation system 
translates a binary component into an intermediate 
representation, provides an application program interface 
through which a user can transform the intermediate 



06/10/2004, EAST Version: 1.4.1 



US 6,662356 Bl 

9 10 

representation, and translates the intermediate representa- 1 contains navigation functions, Table 2 contains query 

tion as transformed by the user into a modified version of the functions, Table 3 contains modification functions, Table 4 

binary. While the invention is not limited to any particular contains instrumentation functions, Table 5 contains output 

arrangement of modules, for sake of clarity exemplary set of translation functions, and Table 6 contains miscellaneous 

modules has been described. One of skill in the art will 5 functions. The tables consist of the API calls, the elements 

readily recognize that the functions attributed to the modules that ex P ose each call > the function provided by the call, and 

described in this section can be assigned to different modules a remarks section. Except where noted, the API calls that do 

without exceeding the scope of the invention. Furthermore, DOt arguments perform their function relative to the 

although the translation and transformation of only one input most recently returned ("current") element of the appropn- 

component (EXE 201) has been illustrated and described 10 ate element class * 0ne of ™ lne 111 ^ readil y 

above, the system can take multiple components, and recognize that the categories below are not rigid and that 

accompanying PDB files, as input. various ^ calls P rovide functions that fit into more than 

one category. 

Functions of Exemplary Embodiments of the Navigation 

Invention 15 Each element class in the IR hierarchy 300 exposes 

navigation functions that enable movement though the ele- 

In the previous section, a system level overview of the ments m fo e hierarchy using "first/' "last," "next," and 

operations of exemplary embodiments of the invention was "previous" functions. Such functions form an "iterator" for 

described. In this section, the particular functions provided me element class. Thus, the component iterator allows a user 

by such exemplary embodiments of the application program ^ to move from component to component in the IR for a 

interface (API) 250 are described. The API 250 and the program, while the procedure iterator allows a user to move 

functions it provides are described in object-oriented pro- fr 0m procedure to procedure in the IR for a component. The 

gramming terms, but one of skill in the art will immediately program, component, procedure, and block APIs further 

perceive that the invention is not so limited. provide a navigation function that returns its first or last 

The API 250 provides an interface to the IR for pre- ^ child element, i.e., the component API enables a user to find 

defined tools 231, direct access 232 by a user, and for the the first or last code or data procedure in the component. The 

output translator (writer) 240. Each element class (type) APIs for the component, procedure, block, and instruction 

present in the IR hierarchy 300 exports an API. Additional element classes also provide a navigation function that 

API calls are provided for specialized uses, such as inserting returns its parent element, Le., the procedure API returns the 

probe code for instrumentation purposes as described in the 30 component element in which it is a procedure element, 

related "Instrumentation and Optimization" patent applica- The iterators for the hierarchical elements are also 

tion. The APIs for the individual element class and the employed by the output translator 240 when translating the 

specialized API combine to make up the API 250. For ease IR into platform-specific instructions as described in the 

in description, similar functions provided by the present related "Cross Module Representation" patent application, 

embodiment of the API 250 are categorized and described The navigation functions of the API 250 are shown in 

together below in conjunction with a series of tables. Table Table 1 below. 



TABLE 1 



IR Element API Call 



Function 



Remarks 



Component, 
Procedure, 
Block, 
Instruction 
Program 



First( ); Ust( ); Nextf ); Prev( ) 



FirstComp( ); LastComp( ) 

Component FirstProcf ); LastProc( ) 

FirstAllProc( ); LastAllProc( ) 

ParentProg( ) 

Procedure FiistAll( ); LastAU( ); NextAIl( ); 
PrevAllC ) 

FirstBlock( ); LastBtock( ) 
FirstAllBlock( ); LastAllBlock( ) 



ParentComp( ) 
Block FirstAll( ); LastAll( ); N«tAIl( ); 

PrevAll( ) 

Firstlnst( ); Lastlnst( ) 

ParentProc( ) 
Instruction ParentBlock( ) 



returns fiist/last/previous/next 
element relative to current element 
of class (code procedures and 
blocks) 

returns first/last component in 
program 

returns first/last code procedure in 
current component 
returns firs Wast procedure (code 
or data) in current component 
returns parent program 

returns first/last/next/previous 
procedure (code or data) relative 
to current procedure in current 
component 

gets fust/last code block in 
current procedure 
gets first/last block (code or data) 
in current procedure 

returns parent component 
returns first/las t/next/previous 
block (code or data) relative to 
current block 

returns first/last instruction in 

current block 

returns parent procedure 

returns parent block for current 

instruction 



retrieved element 
becomes current 
element of class 

create iterator for 
components 
create iterator for 
procedures 
create iterator for 
procedures 

will return NULL if no 
program binary open 
retrieved procedure 
becomes current 
procedure 

create iterator for 
blocks 

create iterator for 
blocks; includes 
unreachable blocks 

retrieved block 
becomes current block 

creates iterator for 
instructions 
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Query 

Each IR hierarchy element class exposes query functions 
that return information about the current element of its class. 
Additional functions necessary to understand the structure of 
the IR, such as entry points, number of child elements, 
imports and exports, and targets for calls and jumps, are also 
provided in the appropriate APIs. The query functions are 
used by the pre-defined tools 231 to determine the appro- 



12 



priate places to place instrumentation probes and opportu- 
nities to optimize the code as described in the related 
"Instrumentation and Optimization" patent application, by 
the user when directly accessing the IR (direct access 232), 
and by the output translator 240 when creating the platform- 
specific output as described in the related "Cross Module 
Representation" patent application. The query functions of 
API 250 are shown in Table 2 below. 



TABLE 2 



IR Element API Call 



Function 



Remarks 



All 

Program, 

Procedure 

Component, 

Procedure, 

Block, 

Instruction 

Component, 

Procedure 

Procedure, 

Block, 

Instruction 

Block, 

Instruction 



Program 
Component 



Procedure 



Block 



GetUserData( ) 
Name( ) 

DbgPrint( ) 



FirstExport( ) 
Firsts cr(component) 

BlockTarget( ) 

ProcTarget( ) 

ImportTarget( ) 

CouutComps( ) 

CountProcs( ) 

CountAllProcs( ) 

InputType( ); OutputType( ) 

[nputNarne( ) 
EntryProcf ) 

BlockFromSymName(name) 

FirstImport( ) 

CountImports( ) 

FindImport(b inary, 
name/ordinal) 
CouatExportsf ) 

TImeStamp( ) 

FindExport (name/ordinal) 

CouatBlocks( ) 

CbuntAllBIocks( ) 

CountInsts( ) 
SymNameCbuffer, offset) 

AlignmentSize( ) 
Blockldf ) 
FLrstReloc( ) 

BlockFollower( ) 
OpCode( ) 

OpcodeStr( ) 

OpcodcGrp( ) 

OpcodeGroupStr( ) 



returns user data 
returns name of element 

returns debugging information 



returns first export for current 
element 

returns entry point into source 
information for current element 

returns target block of current 
element 

returns target procedure of 

current element 

returns target import of current 

element 

returns number of components in 
program 

returns number of code procedures 

in current component 

returns number of all (code or 

data) procedures 

returns type of input/output 

component 

returns name of input component 

returns primary entry point for 

current component 

returns code block corresponding 

to symbol name 

returns first import for current 

component 

counts imports for current 
component 

returns import corresponding to 
name or number in external binary 
counts exports for current 
component 

returns timestamp for current 
component 

returns export corresponding to 
name or number in current 
component 

count code blocks in current 
procedure 

count code and data blocks in 

current procedure 

count instructions in current block 

returns symbol name at offset 

within current block 

returns block alignment 

returns block identifier 

returns entry point into relocation 

information 

returns follower block 
return opcode for current 
instruction 

returns string representation of 

current instruction 

returns opcode group for current 

instruction 

returns string representation of 
opcode group for current 
instruction 



creates an iterator for 
exports 

creates iterator for 
source information 

call, jump, conditional 

jump 

call 



indirect call 



architecture instruction 
set 



includes unreachable 
blocks 



creates iterator for 
relocation information; 
NULL Lf code block 
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TABLE 2-coQtinucd 


IR Element API Call 


FUnction 


Remarks 


OpSizc() 


returns size of primary operand 


0 (NOP), 8 (MOVB), 




for current instruction 


16, 32, 64, etc 


OperandStr( ) 


returns operand for current 






instruction as a string 




Operand( ) 


returns operands for current 






instruction 





Modification 

Each IR hierarchy element class exposes modification 
functions that enable the IR to be changed at all levels. These 



functions are primarily used by the transformation module 
230. The modification functions of the API 250 are shown in 
Table 3 below. 



TABLE 3 



IR Element API Call 



Function 



Remarks 



All 



Component, 

Procedure, 

Block 

Instructions 

Block, 

Instruction 



Program 
Component 



Procedure 



Block 



Dcstroy( ) 

SetUserData(data) 
Removef ) 

Ins ertPrevfelement); 
InsertNext (element) 
SetBlockTargetfblock) 

SetPro clargetfpro cedure) 

SetlmpDrtTarget(import) 

InsertFirs tComp(component) ; 
Ins ertLastComp (component) 

InsertFirs tProc(pro cedure) ; 
InsertLastProc(procedure) 

SetEntryPoint(procedure) 

NewProc(name) 

Createlmport (binary, 
function) 

MergeIR(binary) 



RedirectProc (binary-from, 
name-from, binary-to, name- 
to) 

TuneStamp( ) 

SetName(name) 
Create^omponent, name) 



InsertFirs tBlock(block); 
InsertLastBlockfMock) 

Reverse( ) 

InsertFirs tins t(instruction); 
Ins ertLastInst(instruction) 
CreateCodeBlock( ) 



deletes element from main 

memory 

sets user data 

removes current element 

from parent element 

inserts new element 

before/after current element 

sets target block of current 

element 

sets target procedure of 

current element 

sets target import of current 

element 

inserts new component 
before first or after last 
component in program 
inserts new procedure before 
first or after last procedure in 
component 

sets primary entry point for 
current component 
create new, empty procedure 
in current component 
adds an import into current 
component 

merges current component 
with binary 

redirects an import/external 
procedure 

sets timestamp for current 
component 
sets IR name 
creates new procedure 



inserts new block before first 
block or after last block in 
current procedure 
reverses order of blocks in 
current procedure 
inserts new instruction before 
first or after last instruction 
creates new code block 



CreateDataBlocl^data, size) creates new data block 



SetAlignmentSize( ) 
SctData(data, size) 
SetBlockld(identifier) 
SetBlockFollower (block) 
SetPlatformT(platform) 



must restart navigation 
with different iterator 



within same class 

call or jump, otherwise 

NULL 

call 

indirect call 



inserted at beginning 
of component 
returns code block 
used as call target for 
new import 
can also specify a 
termination routine 
when necessary 



not inserted 
automatically; name 
becomes symbol in 
component 



sets block alignment 

nils data block 

sets block identifier 

sets block as follower block 

specifies platform for emitted 

instructions 



not inserted 
automatically in 
procedure 
not inserted 
automatically in 
procedure 
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TABLE 3 -continued 



IR Element API Call 


Function 


Remarks 


Instruction InsertNext(instruction); 


inserts new instruction 




InsertPrev(instruction) 


before/after current 
instruction 




Create( ) 


creates empty instruction 


not inserted 
automatically into 
block 


Geate(opcode, arguments) 


creates an instruction 


instruction type is 
determined by 
arguments 


Create(instruction) 


copies an instruction 




SetOpcode(opcode) 


sets opcode of current 
instruction 




SetOperand(op erand) 


sets operand of current 
instruction 





Instrumentation 

The instrumentation functions of the API 250 shown in 
Table 4 are used by the pre-defined tools 231 and the user 
direct access 232 provided by the transformation module 
230. Because the component, procedure, block, and instruc- 



tion classes expose instrumentation functions, "probe" code 
20 can be inserted at any level in the IR hierarchy as specified 
by the caller of the API 250 so statistics can be acquired at 
any point in the IR. The commit and revert calls permit the 
caller to determine when and if the instrumentation changes 
requested by the caller should be made to the IR. 



TABLE 4 



IR Element API ail 



Function 



Remarks 



Global 



Component, 

Procedure, 

Block, 

Instruction 

Procedure 



CreateProto(component, binary, 
name) 

QreateSaveData(name, definition) 
Commit( ) 
Revertf ) 

AddCall(element, location) 

AddSaveData (element, location) 

CreateExchangeProc(component, 
binary, function name) 
Exchangc(procedurc) 



creates external code to be 
called from the IR 
creates storage to save data 
commits changes made to IR 
reverts changes made to IR 
inserts a call to external code 
before/after element 
saves data state before/after 
element 

creates new procedure to 
exchange for existing one 
exchange new procedure for 
current procedure 



returns entry block 
for original procedure 



Output Translation 

As described in the related "Cross Module Representa- 
tion" patent application, the output translator 240 emits 

45 platform -specific instructions based on the contents of the 
IR. The output translator 240 relies on flags created by the 
input translation module 210 (described in the related 
"Translation and Transformation" patent application) to 
determine the type of processing to be performed on the 

50 elements of the IR. Additional flags used by the output 
translator 240 are arguments input into the input translator 
210 as indicated below. Both the linker 241 and writer 242 
modules of the output translator 240 access the IR using the 
API calls shown below in Table 5. 



TABLE 5 



IR Element API Call 



Function 



Remarks 



Procedure, 

Block, 

Instruction 



Size() 

Print(fUe name) 
PrintAsm(file name) 



Addr() 



returns size of element 
outputs IR instruction(B) 
outputs disassembled 
platform-specific 
instructionfs) 

returns address of element 
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TABLE 5-continued 



IR Element API Call 



Function 



Remarks 



Procedure, 

Block 

Block, 

Instruction 

Component 



Procedure 



Block 



Instruction 



Raw() 

Islnserted( ) 

CanWritePdb( ) 

IsRereadable( ) 

AssignAddresses( ) 

Writefoutput file name, pdb 
file name, map file name, 
IsRereadable) 

[sExported(companenf) 
LsNoReturn( ) 

HasExcept( ) 

SymName(buffer, 
component) 
Returns( ) 
LsDataBlock( ) 
HasCall( ) 
HasCBranch( ) 

IsUnreachable( ) 
LsObsolete( ) 

IsCairiargetf ) 

IsAddrTakenGlobal( ) 

tsAddrTakenLocal( ) 

IsEntryBlock( ) 



Lslnstrumentatble( ) 
BlockTerminationType( ) 
OrigAddr(component) 
Emitfbuffei) 
IsData( ) 
IsValid( ) 
ReadsMemory( ) 
WritesMemory( ) 
StackMemory( ) 
RegsDef(bit map) 
RegsUse(bit map) 



returns bytes of element 

is element part of original 
binary 

is program data base (PDB) 
file to be created 
can IR be iterated 

compute new addresses 

writes platform-specific 
component into output file, 
and related information into 
PDB file and map file 
is current procedure exported 
does current procedure end in 
a return 

does current procedure 

register an exception 

store symbolic name of 

current procedure 

does block end with return 

code or data block 

does block end with call 

does block end with a 

conditional branch 

is block unreachable 

is block to be deleted from 

output binary 

is block a caD target 

is block an inter-procedure 

address reference 

is block a jump table branch 

target 

is block a possible entry 
point for procedure 



boolean 

boolean; input at IR 
creation time 
boolean; see Write 
API call 

as described in related 
patent application 
as described in related 
patent application 



boolean 
boolean 



can new code be inserted into 
block 

returns termination type of 
block 

returns compiler-emitted 
address of current block 
assemble current block in 
buffer to determine size 
does instruction represent 



boolean 



boolean 
boolean 
boolean 
boolean 

boolean 
boolean 

boolean; direct calls 

only 

boolean 

boolean; intra- 
procedure address 
reference 

boolean; either a call 
target or an inter- 
procedure address 
reference 
boolean 



boolean 



can instructions be emitted as boolean 
platform- specific instruction 
does instruction read from boolean 
main memory 

does instruction write to main boolean 
memory 

does instruction reference an boolean 

offset in the stack 

returns registers denned by 

instruction 

returns registers used by 
current instruction 



Miscellaneous 

The API 250 requires that pre-defined tools use the API 
functions shown in Table 6 to initiate access to the IR. 



TABLE 6 



IR Element API Call Function Remarks 



Program, Open(file name) opens binary for element open program will 

Component open all components 
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TABLE 6-continued 
IR Element API Call Function Remarks 

Component Build( ) builds IR if not previously 

created 

UseBlockFollowers( ) marks appropriate blocks as 
fall-through 



10 



In this section, the particular functions performed by 
computer in executing an exemplary embodiment of an API 
250 to transform and translate an IR for a program, 
component, or set of components has been described with 
reference to Tables 1-6. One of skill in the art will imme- 15 
diate appreciate that functions that perform similar actions 
can be substituted for the functions specified above without 
departing from the scope of the invention. 

Conclusion 2 o 

An application program interface (API) into an hierarchi- 
cal intermediate representation (IR) of a heterogeneous 
program has been described that enables the navigation and 
modification of the IR at all levels of the hierarchy. 
Furthermore, other functions provided by the API return 25 
information about the IR that can be employed by a user in 
understanding the logic flow of the program and by an 
output translator to convert the IR into blocks of platform- 
specific instructions for a new version of the heterogeneous 
program. The API functions are also utilized by pre-defined 30 
program tools to instrument and optimize the IR, and thus 
the heterogeneous program created from the IR. 

Although specific embodiments have been illustrated and 
described herein, it will be appreciated by those of ordinary ^ 
skill in the art that any arrangement which is calculated to 
achieve the same purpose may be substituted for the specific 
embodiments shown. This application is intended to cover 
any adaptations or variations of the present invention. For 
example, those of ordinary skill within the art will appreciate 
the functions shown in Tables 1-6 are not required to be 
implemented in an object-oriented language such as C++, 
but are adaptable to other programming paradigms. The 
terminology used in this application with respect to is meant 
to include all architectural environments that support the ^ 
basic programming constructs embodied in the IR hierarchy. 
Therefore, it is manifestly intended that this invention be 
limited only by the following claims and equivalents 
thereof. 

We claim: 5Q 
1. An application program interface embodied on a 
computer-readable medium for execution on a computer in 
conjunction with an intermediate representation of a hetero- 
geneous program, the application program interface com- 
prising: 55 
a navigation function that returns an element in the 
intermediate representation to a caller of the application 
program interface; 
a query function that returns information about the ele- 
ment in the intermediate representation returned by the 60 
navigation function to the caller; and 
a modification function that modifies the element in the 
intermediate representation as directed by the caller, 
wherein the intermediate representation comprises a 
plurality of platform-neutral elements, wherein the 65 
plurality of platform-neutral elements comprise (a) one 
or more platform-neutral elements derived from a first 



code written for a first computer architecture, and (b) 
one or more platform-neutral elements derived from a 
second code written for a second computer 
architecture, wherein the first computer architecture is 
different from the second computer architecture. 

2. The application program interface of claim 1, wherein 
the element returned by the navigation function is desig- 
nated the current element of its type and the navigation 
function operates relative to the current element of a type 
specified by the caller. 

3. The application program interface of claim 1, wherein 
the navigation function comprises: 

a next function that returns the element of a specified type 
that is next in order within the hierarchy of the inter- 
mediate representation; 

a previous function that returns the element of a specified 
type that is previous in order within the hierarchy of the 
intermediate representation; 

a first function that returns the element of a specified type 
that is first in order within the hierarchy of the inter- 
mediate representation; and 

a last function that returns the element of a specified type 
that is last in order within the hierarchy of the inter- 
mediate representation. 

4. The application program interface of claim 3, wherein 
the order within the hierarchy is relative to an element that 
is one level above the returned element in the hierarchy. 

5. The application program interface of claim 3, wherein 
the navigation function comprises: 

a parent function that returns an element that is one level 
above an element of a specified type in the hierarchy. 

6. The application program interface of claim 1, wherein 
the query function comprises: 

a counting function that enumerates a specified charac- 
teristic of the element returned by the navigation func- 
tion; and 

a control flow function that returns information relating to 
logical connections between the element returned by 
the navigation function and other elements in the 
intermediate representation. 

7. The application program interface of claim 6, further 
comprising: 

an instruction function that returns information on instruc- 
tion structure when the element returned by the navi- 
gation function is an instruction in the intermediate 
representation. 

8. The application program interface of claim 1, wherein 
the modification function comprises: 

a creation function that creates a new element of a 

specified type; 
an insertion function that inserts an element of a specified 

type into the intermediate representation; 
a deletion function that deletes an element of a specified 

type from the intermediate representation; and 
a control flow function that logically links an element of 

a specified type to another element in the intermediate 

representation. 
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9. The application program interface of claim 1, further 
comprising: 

an output translation function that translates the element 
returned by the navigation function into a correspond- 
ing element for a specific computer architecture and 
returns the corresponding element to the caller. 

10. The application program interface of claim 9, wherein 
the output translation function determines the specific com- 
puter architecture based on a flag set by the caller. 

11. The application program interface of claim 9, wherein 
the output translation function writes the corresponding 
element to an output file. 

12. The application program interface of claim 1, further 
comprising: 

an instrumentation function that inserts probe code speci- 
fied by the caller into the intermediate representation at 
a location relative to the element returned by the 
navigation function. 

13. The application program interface of claim 12, 
wherein the probe code includes a call to an external 
component provided by the caller. 

14. A computerized system comprising: 
a processing unit; 

a system memory coupled to the processing unit through 
a system bus; 

a computer-readable medium coupled to the processing 
unit through a system bus; 

an intermediate representation for a heterogeneous pro- 
gram in the system memory; 

a transformation process executing in the processing unit; 
and 

an application program interface executed from the 
computer-readable medium by the processing unit, 
wherein the transformation process calls the applica- 
tion program interface to cause the processing unit to 
modify one or more elements in the intermediate 
representation, wherein the intermediate representation 
comprises a plurality of platform-neutral elements, 
wherein the plurality of platform-neutral elements 
comprise (a) one or more platform-neutral elements 
derived from a first code written for a first computer 
architecture, and (b) one or more platform-neutral 
elements derived from a second code written for a 
second computer architecture, wherein the first com- 
puter architecture is different from the second computer 
architecture. 

15. The computerized system of claim 14, wherein the 
transformation process further calls the application program 
interface to cause the processing unit to navigate through the 
hierarchical intermediate representation to an element in the 
intermediate representation specified by the transformation 
process. 

16. The computerized system of claim 14, wherein the 
transformation process further calls the application program 
interface to cause the processing unit to return information 
about an element in the intermediate representation specified 
by the transformation process. 

17. The computerized system of claim 14, wherein the 
transformation process calls the application program inter- 
face to cause the processing unit to instrument the interme- 
diate representation. 

18. The computerized system of claim 17, wherein the 
transformation process specifies probe code to be inserted 
into the intermediate representation to instrument the inter- 
mediate representation. 

19. The computerized system of claim 18, wherein the 
probe code includes a call to an external component speci- 
fied by the transformation process. 
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20. The computerized system of claim 14, wherein the 
transformation process calls the application program inter- 
face to cause the processing unit to translate an element in 
the intermediate representation into a corresponding element 

5 for a specified computer architecture. 

21. The computerized system of claim 20, wherein the 
transformation process calls the application program inter- 
face to cause the processing unit to set a flag in the 
intermediate representation that specifies the computer 

10 architecture. 

22. A computer-readable medium having computer- 
executable instructions stored thereon to provide an inter- 
face to one or more elements within a hierarchy of an 
intermediate representation of a heterogeneous program 

15 comprising: 

an instruction application interface exposed by an instruc- 
tion element in the hierarchy for navigating, querying, 
modifying, and translating an instruction in the inter- 
mediate representation; 

20 a block application interface exposed by a block element 
in the hierarchy for navigating, querying, and modify- 
ing a block in the intermediate representation; 
a procedure application interface exposed by a procedure 

25 element in the hierarchy for navigating, querying, and 
modifying a procedure in the intermediate representa- 
tion; and 

a component application interface exposed by a compo- 
nent element in the hierarchy for navigating, querying, 

30 and modifying a component in the intermediate 
representation, wherein the intermediate representation 
comprises a plurality of platform-neutral elements, 
wherein the plurality of platform-neutral elements 
comprise: (a) one or more platform-neutral elements 

35 derived from a first code written for a first computer 
architecture, and (b) one or more platform-neutral 
elements derived from a second code written for a 
second computer architecture, wherein the first com- 
puter architecture is different from the second computer 

40 architecture. 

23. The computer-readable medium of claim 22, further 
comprising: 

a program application interface exposed by a program 
element in the hierarchy for modifying and querying 
45 the intermediate representation for the heterogeneous 
program. 

24. A computerized method of interfacing a user process 
to an intermediate representation of a heterogeneous pro- 
gram with the intermediate representation arranged as a 

50 hierarchy of classes, the method comprising: 

issuing, by the user process, an initial navigation call for 
a class within the hierarchy, wherein the initial navi- 
gation call specifies an absolute location within the 
hierarchy for an element in the class; 

55 creating, by an interface process, an iterator for the class 
in response to receiving the initial navigation call; 
returning, by the interface process, the element of the 
class located in the hierarchy at the absolute location, 

60 wherein the element is designated as a current element 
for the class; 

issuing, by the user process, a modification call for the 
class, wherein the modification call specifies a change 
to the intermediate representation relative to the current 
$5 element of the class; and 

changing, by the interface process, the intermediate rep- 
resentation in response to receiving the modification 
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call, wherein the intermediate representation comprises 
a plurality of platform-neutral elements, wherein the 
plurality of platform-neutral elements comprise (a) one 
or more platform-neutral elements derived from a first 
code written for a first computer architecture, and (b) 
one or more platform-neutral elements derived from a 
second code written for a second computer 
architecture, wherein the first computer architecture is 
different from the second computer architecture. 

25. The method of claim 24, further comprising: 
issuing, by the user process, a subsequent navigation call 

for the class, wherein the subsequent navigation call 
specifies a relative location within the hierarchy for an 
element in the class; 
positioning, by the interface process, the iterator for the 
class at the relative location within the hierarchy in 
response to receiving the subsequent navigation call; 
and 

returning, by the interface process, an element of the class 
corresponding to the position of the iterator for the 
class, wherein the element returned is designated as a 
new current element for the class. 

26. The method of claim 25, wherein the iterator is 
positioned relative to the current element of the class. 

27. The method of claim 24, further comprising: 
issuing, by the user process, a subsequent navigation call 

for the class, wherein the subsequent navigation call 

specifies a parent class for the class; 
positioning, by the interface process, an iterator for the 

parent class at a location of an element of the parent 

class that is immediately above the current element in 

the class in the hierarchy in response to receiving the 

subsequent navigation call; and 
returning, by the interface process, the element of the 

parent class corresponding to the position of the iterator 

for the parent class. 

28. The method of claim 24, further comprising: 
issuing, by the user process, a subsequent navigation call 

for the class, wherein the subsequent navigation call 

specifies a child class for the class; 
positioning, by the interface process, an iterator for the 

child class at a location of an element of the child class 

that is immediately below the current element in the 

class in the hierarchy in response to receiving the 

subsequent navigation call; and 
returning, by the interface process, the element of the 

child class corresponding to the position of the iterator 

for the child class. 

29. The method of claim 24, further comprising: 
issuing, by the user process, a query call for the class, 

wherein the query call specifies a characteristic of the 
class; and 

returning, by the interface process, information about the 
characteristic for the current element of the class in 
response to receiving the query call. 

30. An application program interface embodied on a 
computer-readable medium for execution on a computer in 
conjunction with an intermediate representation of a hetero- 
geneous program, the application program interface com- 
prising: 
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a navigation function; 
a query function; and 
a modification function; 

wherein the navigation function is capable of returning a 
first element, a last element, a previous element, or a 
next element relative to a current element, within the 
intermediate representation, to a caller of the applica- 
tion program interface, wherein the intermediate rep- 
resentation comprises a plurality of platform-neutral 
elements, wherein the plurality of platform-neutral 
elements comprise (a) one or more platform-neutral 
elements derived from a first code written for a first 
computer architecture, and (b) one or more platform- 
neutral elements derived from a second code written for 
a second computer architecture, wherein the first com- 
puter architecture is different from the second computer 
architecture. 

31. An application program interface embodied on a 
M computer-readable medium for execution on a computer in 

conjunction with an intermediate representation of a hetero- 
geneous program, the application program interface com- 
prising: 

a navigation function that returns an element in the 
25 intermediate representation to a caller of the application 
program interface; 
a query function that returns information about the ele- 
ment in the intermediate representation returned by the 
navigation function to the caller; 
30 a modification function that modifies the element in the 
intermediate representation as directed by the caller; 
and 

an output translation function that translates the element 
returned by the navigation function into a correspond- 
ing element for a specific computer architecture and 
returns the corresponding element to the caller, wherein 
the output translation function determines the specific 
computer architecture based on a flag set by the caller. 

32. A computerized system comprising: 
a processing unit; 

a system memory coupled to the processing unit through 
a system bus; 

a computer-readable medium coupled to the processing 
45 unit through a system bus; 

an intermediate representation for a heterogeneous pro- 
gram in the system memory; 

a transformation process executed by the processing unit; 
and 

50 an application program interface executed from the 
computer-readable medium by the processing unit, 
wherein the transformation process calls the applica- 
tion program interface to cause the processing unit to 
translate one or more elements in the intermediate 

55 representation into a corresponding one or more ele- 
ments for a specified computer architecture, and 
wherein the transformation process calls the applica- 
tion program interface to cause the processing unit to 
set a flag in the intermediate representation that speci- 

60 fies the computer architecture. 
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